\chapter{Vue d'ensemble}

\section{Diagramme de composants}

\begin{center}
\includegraphics[scale=0.70]{archi_general}
\end{center}

\section{Présentation des composants}

\paragraph*{}

Le schéma précédent présente l'architecture générale de la plateforme.
Celle-ci est divisée en plusieurs composants :\\

\begin{itemize}
\item \textbf{La Warehouse} est une arborescence (système de fichiers) dans laquelle seront stockés les \textit{template}, les tests et les \textit{assignment version} des groupes d'étudiants.
\item \textbf{La base de données interne}\footnote{développée dans le chapitre 7} contiendra les informations relatives aux \textit{assignment}, aux groupes utilisateurs, etc...
\item \textbf{Le serveur Django} sera utilisé en tant que serveur web afin de fournir une interface utilisateur pour SPASS au travers d'un navigateur web.
\item \textbf{La base de données externe} contiendra les informations relatives aux droits des utilisateurs sur la plate-forme web.
\item \textbf{Le terminal} représente l'interface en ligne de commande pour SPASS. Elle sera réservée aux administrateurs car aucune gestion des droits n'y sera intégrée.
\item \textbf{Le core} est l'élément central de l'application. Il a pour rôle de gérer la base de donnée interne et la \textit{Warehouse}. En conséquence, il est le seul à y avoir accès. Toute requête de lecture ou d'écriture par un autre composant sera effectuée par l'intermédiaire d'une API. Celle-ci sera l'interface de dialogue avec le core.
\end{itemize}

\section{Explications}

\paragraph*{}

Le core est un composant inerte. Il n'a pour rôle que de gérer les composants internes de stockage (la base de données interne et la \textit{Warehouse}). Le core vie au sein d'une interface utilisateur au travers d'une API. Celle-ci permet à la dite interface d'effectuer des appels à des routines du core qui permettront d'effectuer des opérations sur les composants internes de stockage.

\paragraph*{}

Un des besoins non fonctionnel prédominant dans ce logiciel réside dans le fait qu'il doit être possible de brancher de nouvelles interfaces utilisateurs à la plate-forme. De ce fait, il est important d'assurer une totale indépendance entre le cœur du logiciel et ses interfaces. De plus, il est important de préserver l'intégrité des composants internes de stockage (aspect sécuritaire). 

Pour répondre à ces critères, nous avons choisi de rendre inaccessible de manière directe ces composants depuis les interfaces. Seul le core y aura accès. Néanmoins, il est nécessaire aux dites interfaces de pouvoir effectuer des accès (lecture ou écriture) sur les dis composants de stockage. C'est pourquoi nous avons décider d'intégrer une API de dialogue avec le core pour ces opérations.
Ce mécanisme est similaire au principe des appels systèmes dans un système d'exploitation. En effet, les accès au matériel sont faits par le noyau lors d'un appel système et non directement par les applications utilisateurs.
Dans SPASS, les accès aux composants internes de stockage seront effectués par le core lors de l'appel d'une fonction de notre API par une interface.

\paragraph*{}

La gestion des droits utilisateurs est relative à la plate-forme web. En effet, le core ne possède pas de système de droits. Ainsi, la plate-forme web a besoin de sa propre base de données (base de données externe) pour gérer ce mécanisme. Nous avons donc choisi d'utiliser directement la base de données fourni par le serveur \textit{Django} afin de lui permettre de gérer directement un système de droits.
